home *** CD-ROM | disk | FTP | other *** search
/ Collection of Tools & Utilities / Collection of Tools and Utilities.iso / graphic / rtnews.zip / RTNV2N4 < prev    next >
Text File  |  1992-09-13  |  28KB  |  647 lines
  1.  _ __                 ______                         _ __
  2. ' )  )                  /                           ' )  )
  3.  /--' __.  __  ,     --/ __  __.  _. o ____  _,      /  / _  , , , _
  4. /  \_(_/|_/ (_/_    (_/ / (_(_/|_(__<_/ / <_(_)_    /  (_</_(_(_/_/_)_
  5.              /                               /|
  6.             '                               |/
  7.  
  8.             "Light Makes Right"
  9.  
  10.                June 21, 1989
  11.                 Volume 2, Number 4
  12.  
  13. Compiled by Eric Haines, 3D/Eye Inc, 2359 Triphammer Rd, Ithaca, NY 14850
  14.     607-257-1381, hpfcla!hpfcrs!eye!erich@hplabs.hp.com, cornell!eye!erich
  15. All contents are US copyright (c) 1989 by the individual authors
  16.  
  17. Contents:
  18.     Introduction
  19.     Hardcopy News (Andrew Glassner)
  20.     New People (Stuart Green, Craig Kolb (and Ken Musgrave), Kaveh Kardan)
  21.     Comments on "Free" Ray Tracers and on Renderman (Kaveh Kardan)
  22.     Minimum Bounding Sphere, continued (Jack Ritter)
  23.     Comments on "A Review of Multi-Computer Ray-Tracing" (Thierry Priol)
  24.     ======== USENET cullings follow ========
  25.     Query: Dataflow Architectures and Ray Tracing (George Kyriazis)
  26.     More on Pixar's Noise Function (Jon Buller)
  27.     DBW_render for Sun 3 (Tad Guy)
  28.     Steel Colors (Eugene Miya)
  29.     Dirty Little Tricks (Jack Ritter)
  30.     Obfuscated Ray Tracer (George Kyriazis)
  31.     Contents of FTP archives, skinner.cs.uoregon.edu (Mark VandeWettering)
  32.  
  33. -----------------------------------------------------------------------------
  34.  
  35. Introduction
  36. ------------
  37.  
  38. First off, please note that I now have a second mail address:
  39.  
  40.     eye!erich@wrath.cs.cornell.edu
  41.  
  42. This is a lot more direct than hopping the HP network through Palo Alto and
  43. Colorado just to get to Ithaca.  We have the connection courtesy of the
  44. Computer Science Dept at Cornell, and they have asked us to try to keep our
  45. traffic down.  So, please don't be a funny guy and send me image files or
  46. somesuch.
  47.  
  48. I just noticed that Andrew and I are out of sync: his hardcopy version is on
  49. Volume 3, and I'm on Volume 2.  One excuse is that the first year of the email
  50. edition is labeled "Volume 0", since it wasn't even called "The Ray Tracing
  51. News" at that point.  An alternate excuse is that I program in "C", and so
  52. start from 0.  Anyway, until maybe the new year, I'll stick with the current
  53. scheme (hey, no one even noticed that last issue was misnumbered (and corrected
  54. on the USENET copy)).
  55.  
  56. -----------------------------------------------------------------------------
  57.  
  58. Hardcopy News
  59. -------------
  60.  
  61. by Andrew Glassner
  62.  
  63.  
  64. The latest issue of the hardcopy Ray Tracing News (Volume 3, Number 1, May
  65. 1989) goes into the mail today, 31 May.  Everyone who is on the softcopy
  66. mailing list should receive a copy.  If you don't get a copy in a week or two,
  67. please let me know (glassner.pa@xerox.com).  It would help if you include your
  68. physical mailing address, so I can at least confirm that your issue was
  69. intended to go to the right place.
  70.  
  71. Contributions are now being solicited for Vol. 3, No. 2.  Start working on
  72. those articles!
  73.  
  74. -----------------------------------------------------------------------------
  75.  
  76. New (and Used?) People
  77. ----------------------
  78.  
  79. The Cornell Program of Computer Graphics computers have all changed their
  80. addresses.  Any computer with the name "*.tn.cornell.edu" is now
  81. "*.graphics.cornell.edu".
  82.  
  83. ------------
  84.  
  85. Stuart Green            - multiprocessor systems for realistic image synthesis
  86. Department of Computer Science
  87. University of Bristol
  88. Queen's Building
  89. University Walk
  90. Bristol.  BS8 1TR
  91. ENGLAND.
  92. green@uk.ac.bristol.compsci
  93.  
  94. I am working on multiprocessor implementations of algorithms for realistic
  95. image synthesis.  So far, this has been restricted to straightforward ray
  96. tracing, but I hope to look at enhanced ray tracing algorithms and radiosity.
  97. I've implemented a ray tracer on a network of Inmos Transputers which uses
  98. mechanisms for distributing both computation and the model data amongst the
  99. processors in a distributed memory MIMD system.
  100.  
  101. ------------
  102.  
  103. Craig Kolb (and Ken Musgrave)
  104.  
  105. My primary interests include modeling natural phenomena, realistic image
  106. synthesis, and animation.
  107.  
  108. I can be reached at:
  109. Dept. of Mathematics
  110. Yale University
  111. P.O. Box 2155
  112. Yale Station
  113. New Haven, CT  06520-2155
  114. (203) 432-7053
  115.  
  116. alias    craig_kolb    craig@weedeater.math.yale.edu
  117. alias    ken_musgrave    musgrave-forest@yale.edu
  118.  
  119. ...I've just started looking into ray/spline intersection.  We do a lot of
  120. heightfield-tracing 'round here, and in the past have rendered them using a
  121. triangle tessellation.  I'm giving splines a shot in order to render some
  122. pictures of eroded terrain for our SIGGRAPH talk.  I notice that you list
  123. spline intersection among your primary interests.  What sort of methods have
  124. you investigated?  At the moment I've implemented (what I assume is) the
  125. standard Newton's method in tandem with a DDA-based cell traversal scheme (as
  126. per our SIGGRAPH paper).  Although this works, it's not exactly blindingly
  127. fast...  Do you know of any 'interesting' references?
  128.  
  129. ------------
  130.  
  131. Kaveh Kardan
  132. Visual Edge Software Ltd.
  133. 3870 Cote Vertu
  134. Montreal, Quebec H4R 1V4
  135. (514)332-6430
  136. larry.mcrim.mcgill.edu!vedge!kaveh
  137.  
  138. I graduated with a BS in Math from MIT in 1985, did some work in molecular
  139. graphics at the Xerox Research Centre of Canada (XRCC), wrote the renderer at
  140. Neo-Visuals (now known as SAS Canada) -- which included a raytracer --, and the
  141. animation stuff at Softimage.  I'm currently working at Visual Edge on the UIMX
  142. package: an X Windows user interface design system.
  143.  
  144. Regarding the Softimage raytracer: it was written by Mike Sweeney (who used
  145. to be at Abel, and who did "Crater Lake" at Waterloo).
  146.  
  147. I will also be acting as a mail forwarder for Mike, as Softimage is not on any
  148. networks.  So in effect, you should probably include Mike in the mailing list
  149. as well, with my address -- or somehow let people know that he can be reached
  150. tc/o me.
  151.  
  152. If I may make some comments about the stuff I have read so far in the back
  153. issues:
  154.  
  155. ====================
  156.  
  157. Jeff Goldsmith writes:
  158.  
  159. >    I don't get it.  Why doesn't every CG Software vendor supply a
  160. >ray tracer.  It's definitely the easiest renderer to write.  Yes,
  161. >they are slo-o-o-o-o-o-w, but they sound glitzy and (I bet) would
  162. >stimulate sales, even if buyers never used them.
  163.  
  164. Having worked at two CG Software companies, I know firsthand how the "to do"
  165. list grows faster than you can possibly implement features (no matter how many
  166. programmers you have -- c.f."The Mythical Man-Month").
  167.  
  168. Jeff is right that ray tracing sounds glitzy, and, yes, it is another factor to
  169. toss into the sales pitch -- but it is not at all clear that it is worth the
  170. effort.
  171.  
  172. Most (if not all) ray tracers assume either infinite rendering time or infinite
  173. disk space.  In the real world (a 68020 and a 144Meg disk) this is not the
  174. case.  The raytracer I wrote at Neo Visuals was written in Fortran -- ergo no
  175. dynamic memory allocation -- so I had to work on optimizing it without
  176. significantly increasing the memory used.  This mostly involved intelligently
  177. choosing when to fire rays.  The renderer performs a Watkins-style rendering,
  178. and fires secondary rays from a pixel only if the surface at that pixel needs
  179. to be raytraced.  Memory constraints prevented me from using any spatial
  180. subdivision methods.
  181.  
  182. Yes, ray traced images are great sales tools.  They are also sometimes not
  183. entirely honest -- novice users ("I want a system to animate Star Wars quality
  184. images, about ten minutes of animation a day on my XT") are not aware of the
  185. expense of raytracing, and very few salesmen go out of their way to point this
  186. out.  However, these same users, unsure of the technology, put together a list
  187. of buzzwords (amongst them "raytracing") and go out to find that piece of
  188. software which has the most features on their list.  Hence I coined the phrase
  189. "buzzword compatible" while at Neo-Visuals (and also "polygons for polygons
  190. sake" -- but that's another story).
  191.  
  192. I have also seen demos, animations, and pictures at trade shows, presented by
  193. hardware and softwar